home *** CD-ROM | disk | FTP | other *** search
/ Freaks Macintosh Archive / Freaks Macintosh Archive.bin / Freaks Macintosh Archives / Textfiles / zines / Phrack / Phrack Issue 53.sit / 53 / P53-01 next >
Text File  |  1998-07-09  |  11KB  |  215 lines
  1. ---[  Phrack Magazine   Volume 8, Issue 53 July 8, 1998, article 01 of 15
  2.  
  3.  
  4. -------------------------[  P H R A C K     5 3     I N D E X
  5.  
  6.  
  7. --------[  Rumble in the Mumble
  8.  
  9.  
  10.     More than 6 months have passed since our last offering.  My most humble,
  11. sincere and heartfelt apologies.  At long last, here we are.  Better late then
  12. never, that's what I always say.  Unless of course, the late version sucks,
  13. then I just like to disavow it entirely.  Well, here we go again.  Another
  14. Phrack issue to glorify behavior which would otherwise be classified as
  15. sociopathic or frankly psychotic (according to Mich Kabay).  More of what you
  16. want, more of what you need.  Technical articles on fanatically enticing
  17. topics, lines and lines of glorious source, another gut-busting installment of
  18. Loopback, and of course, the News.  Mammas, don't let your babies grow up to
  19. be hackers.  Or hookers for that matter.
  20.  
  21.     Alright.  Let's get down to business.  Let's talk remote attack paradigms.
  22. Remote attack paradigms can fall into one of two types, based off of the
  23. standard client/server communication paradigm (we are glossing over any
  24. extensions to the model like client to client or server to server stuff).  The
  25. two attack types are client to server (server-centric) and server to client
  26. (client-centric).  Server-centric attacks are well known, understand and
  27. documented.  Client-centric attacks are an area that is often overlooked, but
  28. is definitely fertile ground for exploitation.  Below we look at both.
  29.  
  30.  
  31. ----[  Server-Centricity
  32.  
  33.     Historically, the vast majority of remote attacks have been server-centric.
  34. Server-centric, in this scope, refers to attacks that target server (or daemon)
  35. programs.  A common (and frequently reoccurring) example is sendmail.  The
  36. attack targets a server (the sendmail daemon) and approximates a client (the
  37. exploit program).  There are several reasons why this has been the trend:
  38.  
  39.     -   Server programs typically run with elevated privileges.  Server
  40.         programs usually require certain system resources or access to special
  41.         files that necessitate privilege elevation (of course we know this
  42.         doesn't have to be the case; have a look at POSIX 6).  A successful
  43.         compromise could very well mean access to the target system at that
  44.         (higher) privilege level.
  45.  
  46.     -   Discretion is the attacker's whim.  The client/server message paradigm
  47.         specifies that a server provides a service that a client may request.
  48.         Servers exist to process clientele requests.  As per this model, the
  49.         attacker (client) makes a request (attack) to any server offering
  50.         the service and may do so at any point.
  51.  
  52.     -   Client codebase is usually simple.  Dumb client, smart server.  The
  53.         impact of this is two-fold.  The fact that server code tends to be
  54.         more complex means that it is tougher to audit from a security
  55.         stand-point.  The fact that client code is typically smaller and less
  56.         complex means that exploitation code development time is reduced.
  57.  
  58.     -   Code reuse in exploitation programs.  Client-based exploitation code
  59.         bases are often quite similar.  Code such as packet generators and
  60.         buffer overflow eggs are often reused.  This further cuts down on
  61.         development time and also reduces required sophistication on the part
  62.         of the exploit writer.
  63.  
  64.     All of these make server-centric attacks enticing.  The ability to
  65. selectively choose a program to attack running with elevated privileges and
  66. quickly write up exploit code for it is a powerful combination.  It is easy to
  67. see why this paradigm has perpetuated itself so successfully.  However, up
  68. until recently it seems another potentially lucrative area of exploitation has
  69. gone all but overlooked.
  70.  
  71.  
  72. ----[  Client-Centricity
  73.  
  74.     An often neglected area of exploitation is the exact reverse of the above:
  75. client-centricity.  Client-centric attacks target client programs (duh).  The
  76. types of programs in this category include: web browsers (which have seen more
  77. then their share of vulnerabilities) remote access programs, DNS resolvers and
  78. IRC clients (to name a few).  The benefits of this attack model are as follows:
  79.  
  80.     -   Automated (non-discretionary) attacks.  We know that, under the
  81.         previous paradigm, the attacker has complete autonomy over who s/he
  82.         attacks.  The benefit there is obvious.  However, non-discretionary
  83.         attacking implies that the attacker doesn't even have to be around
  84.         when the attack takes place.  The attacker can set up the server
  85.         containing the exploit and actually go do something useful (tm).
  86.  
  87.     -   Wide dispersement.  With client-centric attacks you can gain a wider
  88.         audience.  If a server contains a popular service, people from all over
  89.         will seek it out.  Popular websites are constantly bombarded with
  90.         clientele.  Another consideration: server programs often run in
  91.         filtered environments.  It may not be possible for an attacker to
  92.         connect to a server.  This is rarely the case in client-centric 
  93.         attacks.
  94.  
  95.     -   Client codebase not developed with security in mind.  If you think
  96.         server code is bad, you should see some client code.  Memory leaks and
  97.         stack overruns are all too common.
  98.  
  99.     -   Largely an untapped resource.  There are so many wonderful holes
  100.         waiting to be discovered.  Judging at how successful people have been
  101.         in finding and exploiting holes in server code, it goes to figure that
  102.         the same success can be had in client code.  In fact, if you take into
  103.         account the fact that the codebase is largely unaudited from a
  104.         security perspective, the yields should be high.
  105.  
  106.     For all the above reasons, people wanting to find security holes should
  107. be definitely be looking at client programs.  Now go break telnet.
  108.  
  109.  
  110. Enjoy the magazine.  It is by and for the hacking community.  Period.
  111.  
  112.  
  113. -- Editor in Chief ----------------[  route
  114. -- Phrack World News --------------[  disorder
  115. -- Phrack Publicity ---------------[  dangergirl
  116. -- Phrack Librarian ---------------[  loadammo
  117. -- Soother of Typographical Chaos -[  snocrash
  118. -- Hi!  I'm an idiot! -------------[  Carolyn P. Meinel
  119. -- The Justice-less Files ---------[  Kevin D. Mitnick (www.kevinmitnick.com)
  120. -------- Elite -------------------->  Solar Designer
  121. -- More money than God ------------[  The former SNI
  122. -- Tom P. and Tim  N. -------------[  Cool as ice, hot as lava.
  123. -- Official Phrack Song -----------[  KMFDM/Megalomaniac
  124. -- Official Phrack Tattoo artist --[  C. Nalla Smith
  125. -- Shout Outs and Thank Yous ------[  haskell, mudge, loadammo, nihilis, daveg,
  126. -----------------------------------|  halflife, snocrash, apk, solar designer,
  127. -----------------------------------|  kore, alhambra, nihil, sluggo, Datastorm,
  128. -----------------------------------|  aleph1, drwho, silitek
  129.  
  130.  
  131. Phrack Magazine V. 8, #53, xx xx, 1998.  ISSN 1068-1035
  132. Contents Copyright (c) 1998 Phrack Magazine. All Rights Reserved.  Nothing
  133. may be reproduced in whole or in part without written permission from the
  134. editor in chief.  Phrack Magazine is made available quarterly to the public,
  135. free of charge.  Go nuts people.
  136.  
  137. Contact Phrack Magazine
  138. -----------------------
  139. Submissions:        phrackedit@phrack.com
  140. Commentary:         loopback@phrack.com
  141. Editor in Chief:    route@phrack.com
  142. Publicist:          dangergrl@phrack.com
  143. Phrack World News:  disorder@phrack.com
  144. Submissions to the above email address may be encrypted with the following key:
  145.  
  146. -----BEGIN PGP PUBLIC KEY BLOCK-----
  147. Version: 2.6.2
  148.  
  149. mQENAzMgU6YAAAEH/1/Kc1KrcUIyL5RBEVeD82JM9skWn60HBzy25FvR6QRYF8uW
  150. ibPDuf3ecgGezQHM0/bDuQfxeOXDihqXQNZzXf02RuS/Au0yiILKqGGfqxxP88/O
  151. vgEDrxu4vKpHBMYTE/Gh6u8QtcqfPYkrfFzJADzPEnPI7zw7ACAnXM5F+8+elt2j
  152. 0njg68iA8ms7W5f0AOcRXEXfCznxVTk470JAIsx76+2aPs9mpIFOB2f8u7xPKg+W
  153. DDJ2wTS1vXzPsmsGJt1UypmitKBQYvJrrsLtTQ9FRavflvCpCWKiwCGIngIKt3yG
  154. /v/uQb3qagZ3kiYr3nUJ+ULklSwej+lrReIdqYEABRG0GjxwaHJhY2tlZGl0QGlu
  155. Zm9uZXh1cy5jb20+tA9QaHJhY2sgTWFnYXppbmU=
  156. =1iyt
  157. -----END PGP PUBLIC KEY BLOCK-----
  158.  
  159. As always, ENCRYPTED SUBSCRIPTION REQUESTS WILL BE IGNORED.  Phrack goes out
  160. plaintext.  You certainly can subscribe in plaintext.
  161.  
  162. phrack:~# head -20 /usr/include/std-disclaimer.h
  163. /*
  164.  *  All information in Phrack Magazine is, to the best of the ability of the
  165.  *  editors and contributors, truthful and accurate.  When possible, all facts
  166.  *  are checked, all code is compiled.  However, we are not omniscient (hell,
  167.  *  we don't even get paid).  It is entirely possible something contained
  168.  *  within this publication is incorrect in some way.  If this is the case,
  169.  *  please drop us some email so that we can correct it in a future issue.
  170.  *
  171.  *
  172.  *  Also, keep in mind that Phrack Magazine accepts no responsibility for the
  173.  *  entirely stupid (or illegal) things people may do with the information
  174.  *  contained here-in.  Phrack is a compendium of knowledge, wisdom, wit, and
  175.  *  sass.  We neither advocate, condone nor participate in any sort of illicit
  176.  *  behavior.  But we will sit back and watch.
  177.  *
  178.  *
  179.  *  Lastly, it bears mentioning that the opinions that may be expressed in the
  180.  *  articles of Phrack Magazine are intellectual property of their authors.
  181.  *  These opinions do not necessarily represent those of the Phrack Staff.
  182.  */
  183.  
  184. -------------------------[  T A B L E   O F   C O N T E N T S
  185.  
  186.  1 Introduction                                            Phrack Staff   11K
  187.  2 Phrack Loopback                                         Phrack Staff   33K
  188.  3 Line Noise                                              various        51K
  189.  4 Phrack Prophile on Glyph                                Phrack Staff   18K
  190.  5 An Overview of Internet Routing                         krnl           50K
  191.  6 T/TCP Vulnerabilities                                   route          17K
  192.  7 A Stealthy Windows Keylogger                            markj8         25K
  193.  8 Linux Trusted Path Execution redux                      K. Baranowski  23K
  194.  9 Hacking in Forth                                        mudge          15K
  195. 10 Interface Promiscuity Obscurity                         apk            24K
  196. 11 Watcher, NIDS for the masses                            hacklab        32K
  197. 12 The Crumbling Tunnel                                    Aleph1         52K
  198. 13 Port Scan Detection Tools                               Solar Designer 25K
  199. 14 Phrack World News                                       Disorder       95K
  200. 15 extract.c                                               Phrack Staff   11K
  201.  
  202.                                                                          482K
  203.  
  204. -----------------------------------------------------------------------------
  205.  
  206.     " The advent of information availability and a rise in the number people
  207.     for whom the net has always been 'the norm' is producing a class of users
  208.     who cannot think for themselves.  As reliance upon scripted attacks
  209.     increases, the number of people who personally possess technical knowledge
  210.     decreases. "
  211.  
  212. -----------------------------------------------------------------------------
  213.  
  214. ----[  EOF
  215.